1. Field of the Invention
Exemplary embodiments of the present invention relate to electronic messaging, and more particularly, to informational header fields in electronic messages.
2. Description of Background
In computer communication networks, one method of communication is electronic mail (email), in which a sending user prepares and sends a message over some form of computer network to a receiving user, usually on a remote system. Most email clients, which are front-end computer programs that are used to read, write, and send email messages, also provide software to facilitate reading, saving, printing and replying to email. Because email messages can be sent at any time across the world as easily as across the office, to a group of people or a single recipient, without the user leaving his or her desk, email can provide considerable benefits over traditional paper based memos and postal systems. Until recently, the use of electronic mail was the single biggest generator of traffic volume on the Internet.
One of the many benefits of email is that it is easy to send a message to many people at once, simply by specifying several recipient addresses. This facilitates easy group communication, because each recipient can then do a group reply to send a response to each of the people who were sent the original message. An electronic mailing list, a special usage of email that allows for the widespread distribution of information to many Internet users, provides a more formalized way for groups to exchange ideas and information. Such a mailing list is similar to a traditional mailing list—a list of names and addresses—as might be kept by an organization for sending publications to its members or customers. An electronic mailing list is essentially an “alias” email address that will result copies of the messages that are sent to this address via Simple Mail Transfer Protocol (SMTP) being resent to all email addresses in a list of recipients on the mailing list when the mailing list is resolved or transformed into the recipient list by an automatic messaging agent (SMTP specifications are defined in “Request for Comment” (RFC) 2821, published by the Internet Society in April 2001, available on the Internet at http://www.ietf./org/rfc/rfc2821.txt, and herein incorporated by reference). Aliases are short forms for email addresses that save typing. The process of transforming and resending is designated “expansion” of the mailing list.
In a “nested list”, a recipient on a mailing list can be another mailing list. Nested lists, which can have a hierarchical structure, are used for efficiency reasons and to distribute the management of different parts of the recipient list. Often, particularly in large organizations, a mailing list will be comprised of a deeply nested set of sublists and recipients. Using a hierarchical structure, messages intended for receipt by all recipients on the entire set of lists can be sent to the top list, while messages intended for only a branch of the tree can be sent to the top of that branch (that is, the intended sublist). As a message sent to nested list is relayed through messaging agents en route to the eventual recipients, the top list and each sublist will be expanded by the messaging agent assigned responsibility for that mailing list, and any further required expansion will be left to other “downstream” messaging agents.
The use of nested mailing lists, while efficient for the sender, does not support the use of mail rules for the mailbox files maintained by the recipients' email client applications. As an example, the following scenario is presented involving an enterprise having a developer A who is assigned to the ‘Client’ project and a product manager B who is responsible for all collaboration product portfolios. A's email address is listed in the ‘Client Team—India’ mailing list, and therefore, A has set up a mail rule in his email client directing that all received messages addressed to ‘Client Team—India’ be automatically moved to his custom mail folder called ‘Project communications’. Frequently, B needs to send messages to the protected ‘Collaboration project teams’ mailing list, which in turn resends the messages to the ‘Client Team’ and ‘Server Team’ mailing sublists. The ‘Client Team’ mailing list is set up to further resolve to the ‘Client Team—India’ and ‘Client Team—China’ sublists. When B's messages sent to the protected ‘Collaboration project teams’ mailing list are retrieved by A's email client, A's mail rule will fail to move the messages to the intended custom folder. Rather, because B's messages will be received by A's email client as being addressed to ‘Collaboration project teams’ and not explicitly addressed to ‘Client Team—India’, B's messages will likely be received in A's general inbox folder. Because A is a developer, A's email client is not configured to expand the protected ‘Collaboration project teams’ mailing list to identify B's messages as being ultimately sent to A in his role as a recipient on the ‘Client Team—India’ mailing list. Furthermore, maintaining a mail rule for each mailing list from which A receives messages may be not efficient, as nested mailing lists tend to be highly dynamic, and A may receive messages from a top mailing list as a recipient on more than one nested sublist of the top mailing list.